A. Field of the Invention
The present invention relates to methods and systems for enabling trust in a federated collaboration. More specifically, the present invention relates to systems and methods for enabling single sign-on access to resources by providing explicit, transitive multilateral trust within a federation that involves a trusted third party.
B. Description of the Related Art
Since its inception, the Internet has undesirably enabled unauthorized entities to gain access to information belonging to others. As the presence of the Internet has grown, so have the needs of organizations to store and transmit information securely. Early on, the Internet provided users little if any security. Information residing on unsecured computers connected to the Internet was at risk of invasion and access by unauthorized parties. Unencrypted information packets transmitted through the Internet to other computers could be intercepted and read by entities, authorized or not, with equipment for doing so. Such a lack of security left organizations open to attack, theft of information, and potential fraud.
As businesses expanded in scope and complexity, business processes also expanded beyond organizational boundaries along with technological systems enabling secure access to those business processes. For example, an organization with several thousand employees who require access to 401(k) information, a health care service provider, a child care provider, and off-site document management services faces a significant identity management workload. Scaling IT user identity systems to handle transactions meeting the needs of such large organizations increases complexity exponentially due primarily to the fact that current IT based security and encryption methods were designed at a time when enterprises operated in isolation.
In basic form, user identification involves the use of “credentials,” typically a username and password transmitted over a network and authenticated via various methods. Such information must typically be entered and transmitted each time a secure resource is accessed by a user. This method is cumbersome for many reasons, particularly in that it requires accounts maintaining identity and authorization information be set up and provisioned at many different secured service providers, requires users to remember many potentially different usernames and passwords, and often provides no encryption of data, thereby rendering the identity information vulnerable to attack. Further, while a user accessing a secure resource may be identified, there may be no mechanism by which that user may verify the identity of the service provider. Such a lack of two-way security may result in compromised information due to actions taken by unauthorized parties. Regardless of the form of the credentials used, their purpose is to bind a user to their identity within the context of an account. An account includes a collection of identity attributes about a user. These attributes are traditionally stored redundantly and with varying degrees of accuracy, freshness, and consistency in several repositories. Identity attributes associated with accounts typically include users' unique identifiers, names, postal addresses, organizational affiliations, and roles in those organizations.
Public Key Infrastructure (PKI) was introduced to provide an increased level of confidence for exchanging information over an increasingly insecure Internet. PKI is generally the use of a public/private key pair for encryption and proof of identity. Depending on how it is implemented, PKI generally offers its users assurance of the confidentiality and integrity of information sent and received electronically, and assurance of the source and destination of that information. This is accomplished using a mathematical technique called public key cryptography or asymmetric key cryptography, whereby a pair of related cryptographic keys—public and private—are used to enable authentication, message encryption, session confidentiality, digital signatures, trusted time-stamping, and other security features. To support these features with public key cryptography, public keys are strongly bound to a subject's identity on a “public key certificate,” which is issued by a certificate authority (CA). CAs generally operate under published certificate policies (CPs) and certification practice statements (CPSs), and are thoroughly audited prior to initiating operations, and throughout their operational lifecycle. One practice that a CA may use to strengthen the binding of a subject's credential to that subject's identity is to require the subject, prior to certificate issuance, to be proofed in person by a trusted agent of the CA and to bring various legal documents, including passports and birth certificates, to that proofing session. Upon issuance by CA, a public key certificate may be distributed through various means and channels, including insecure connections.
PKI is an important component of a unified, end-to-end identity management (IdM) environment, but it's not the only critical trust and security infrastructure. Organizations have invested heavily in PKI to support strong assurance on the authentication process, which ensures that person presenting credentials to an online application or other resource is in fact who they claim to be.
However, PKI does not adequately address the problem of linking an authoritative digital identity with an e-mail, local area network (LAN), enterprise resource planning (ERP), or other application accounts—a function known as “account provisioning.”
In addition, PKI digital certificates don't provide sufficient information that applications need for authorization—in other words, to determine whether a particular user should be granted access to enterprise resources, such as applications, documents and data records.
Furthermore, PKIs haven't been universally deployed and integrated with all applications, platforms, and devices. Among other issues, it's quite difficult to set up and administer all of the requisite trust relationships among PKIs in use through a heterogeneous, multinational, B2B supply chain.
Consequently, PKI-based security infrastructures are not sufficient to address the requirements of distributed, multi-organizational identity, account, and credential management environments. Frequently, one of the requirements—and risks—of distributed identity management environments, is the need for each organization to maintain separate identity accounts—with associated user attributes—for each user wishing to access the secure resources. This creates additional risks, for example, accounts on remote systems may not be managed to the same standards as an organization may use internally. Without a consistent standard of account management, it is possible that the organization's users may create and access external accounts without account managers being aware the accounts exist. This may lead to problems such as, employees who leave the organization maintaining access to other partner sites as though they were still employed with their former organization. Removing the duplication and ambiguity, while providing means for a comprehensive audit, may help mitigate such risks and free account managers for other, more important tasks.
For an organization with many users, management of accounts within the organization may require the resources of many additional employees, thereby adding significant cost. Additionally, entities that manage a large number of applications (e.g., an entity providing Human Resource services to many partner organizations), must manage a very large number of additional user accounts, potentially one account per service per user. Therefore, the total work required to manage all accounts, internally and for partner organizations, is potentially equal to the number of employees plus partner employees multiplied by the number of externally managed applications those employees use. For every organization and application that can depend on authentication by a single entity, the user management burden is significantly reduced. By eliminating the need to manage multiple accounts for a single user, associated account management costs can also be dramatically reduced.
A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies. Typically, federated domains honor each others' decisions within well-defined spheres of operation.
Federated IdM is an emerging industry best practice for dealing with the heterogeneous, dynamic, loosely coupled trust relationships that characterize companies' external and internal supply chains. Federated IdM enables strong authentication, Web single sign-on (SSO), role-based access control (RBAC), and other trust-enabled security services across diverse identity, security, and application domains.
Federated IdM environments define what amounts to an abstraction layer over the legacy identity and security environments of diverse domains. Each domain maps its local identities and attributes to the agreed-upon schemas and syntaxes. Federated IdM environments generally leverage and interface a broad range of existing, heterogeneous infrastructure services. Consequently, domains can retain their internal directory, meta-directory, account provisioning, and PKI services, as long as their external IdM interfaces implement a common federated IdM standard such as Security Assertion Markup Language (SAML), or other identity and attribute conveyance format.
Federated IdM is enabled through standards, technologies, and agreements that allow organizations to interchange and validate identities, attributes, roles, and permissions across autonomous domains. Within a federated IdM environment, a user can log into his or her company's domain and then leverage that authentication to access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by local and external administrators.
A federated business model enables an enterprise to share selected identity information about their users with trusted partners. This enables partner companies to make access management decisions without having to administer distinct identity accounts for third-party users. Federation allows autonomous domains to maintain control over their respective users' identities, as well as over the resources that they allow internal and external users to access. In a federated environment, identity information need not be replicated or synchronized across diverse federated domains. Instead, identities and other attributes can continue to be stored, managed, and controlled locally by the administrators of the domain in which they are registered.
Federated IdM is well-suited to the heterogeneous, decentralized, loosely coupled fabric of modern e-commerce. In the real world, no one administrator has responsibility for registering all users, activating all accounts, and granting all access privileges in B2B environments, or in many large, multidivisional companies. At the same time, though, administrators of the various domains don't want to give up local control and storage of identity information. Consequently, federated IdM may be regarded as a mechanism for enterprises to address the authorization challenge, while not taking on the burden of third-party user account management.
Federation may be bilateral or multilateral in topology. FIG. 1 depicts a bilateral federation model, in which users' identities are managed by an “identity provider” (Identity provider), such as their employer, and resources (such as applications and databases) are managed by an external “service provider” (service provider), such as a partner organization. In this example, the user registers an identity, account, credentials, and other attributes at its employer and securely accesses information hosted at a single partner organization. Partners in a federated identity management system depend on one another to authenticate their respective users and vouch for their identity and access privileges. In this particular bilateral federation example, transitive trust does not exist; consequently, the Identity provider must maintain separate federation arrangements, implemented through processes and technology, with each partner service provider. If two organizations implementing disparate identity management systems attempt to partner, each must adapt and modify their current system to further enable interaction with the system of the other. If one partner organization elects to change identity management systems at a point later in time, the other partner is faced with a choice to adapt, or cease federated interactions with that partner. For example, there are multiple standard formats, syntaxes, and protocols which an organization may choose from in order to implement such a system including, Security Assertion Markup Language (SAML), Service Provisioning Markup Language (SPML), or X.509 Attribute Certificates. This flexibility leads to difficulties when attempting cross organization trust relationships. When disparate protocols are utilized by partnering organizations due to lack of a standard or for other reasons, the partner organizations must either introduce additional systems and software for translating assertions or cease interacting with the partner organization on the federated level.
FIG. 2 depicts a multilateral federation that has been composed from a mesh of bilateral arrangements among many partnering organizations. One of skill in the art will recognize that such a system leads to high costs due to the requirements for obtaining such a large number of agreements, as well as the fact that management/enforcement of such agreements becomes increasingly more difficult as the number of agreements increases.
One of skill in the art will further recognize that while federation provides a sound technological underpinning that can enable flexible e-business processes, federation depends on the strength of the trust between Identity providers and service providers. That trust, in turn, is based on each organization's understanding and acceptance of partnering organizations' identity, credential, and account management policies and practices. Currently, there is no open, industry-standard identity policy framework that overcomes the shortcomings of the related art, that encompasses legal, financial, operational and technical standards, and that allows enterprises to publish their policies and practices in a common format. Therefore, it is apparent to one of skill in the art that there is a need for such a standard identity policy and practice framework, which would allow enterprises to explicitly declare their own identity, credential, and account management policies and practices, and to explicitly review, accept, and trust partnering organizations' equivalent policies and practices.
It will also be apparent to one of skill in the art that there is a need for a security architecture in which multilateral trust is facilitated by a trusted third party, thereby allowing multiple parties in a community of interest to accept specific identity claims, assertions, tokens, and credentials from one another without requiring prearranged trust agreements between each participating organization.
This invention addresses these needs in various embodiments of systems and methods for enabling an explicit, multilateral, transitive, federated trust architecture that includes a trusted third party and a standard identity policy and practice framework.